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REASONS FOR PRE- APPEAL BRIEF REQUEST FOR REVIEW 

Applicants request a pre-appeal brief review of the rejection of claims 1-20 as obvious 
(35 U.S.C. § 103(a)) over Bates (U.S. Patent No. 6,977,927) in view of Phillips (U.S. Patent No. 
5,321,828). 

Applicants first request review on the grounds that Phillips is non-analogous art because 
Phillips is not in the field of the endeavor or pertinent to the claimed subject matter. Philips 
concerns an emulator for debugging microprocessors, whereas the claims concern 
communication between platform-specific and platform-independent processes in a SAN. 

In the Advisory Action dated October 30, 2006 ("Advisory Action"), the Examiner 
contended that Phillips is analogous art because it teaches the trait of a command line 
communication between processing systems and hence is deemed to be in the same field of 
endeavor. Applicants traverse because Phillips discussion of command line interfaces does not 
establish that Phillips is in the same field of endeavor or pertinent. See, MPEP 2141.01(a). 

Phillips is directed to an in-circuit emulator (ICE) to debug and develop microprocessors. 
According to the "Field of the Invention", Phillips "relates generally to microcomputer systems 
and more particularly to instruments that enable the development and debugging of the hardware 
and software in target machines by the emulation and control of the target CPU within the target 
environment" (Phillips, col. 1, lines 6-12). The claims, on the other hand, are directed to 
communication between platform-specific and platform-independent processors on different 
digital data processors in a storage area network (SAN). Applicants submit that an in-circuit 
emulator used for debugging machines is in a different field of endeavor than a SAN executing 
two operating systems and platform independent processes that invoke command line interfaces 
to effect execution of platform specific processes. 

Further, Applicants submit that the in-circuit emulator of Phillips used to debug 

microprocessors is not reasonably pertinent to the particular problems with which the claims of 

the present application are concerned — communication between platform-specific and platform 

independent processes on different digital data processors in a SAN or other network 

environment. Applicants submit that an inventor working on issues related to the claimed 
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communication between platform-independent and platform-specific processors in a SAN would 
not be motivated to a command line interface to control an in-circuit emulator to debug 
microprocessors. The Examiner has not provided any grounds that refute Applicants specific 
facts as to why Philips is non-analogous for not being in the same field of endeavor and not 
pertinent. 

Applicants also request review because even if one were to combine Phillips and Bates 
(which Applicants submit is improper for the reasons explained above), the cited combination 
still does not teach or suggest the claim requirements for the following reasons. 

With respect to independent claims 1, 15, and 21, the Examiner cited col. 23, lines 50-67 
of Phillips as teaching the claim requirements of first and second common platform independent 
processes executing on first and second processors, wherein the first and second common 
platform independent processes invoke and communicate with a first and second command line 
interfaces, respectively, to effect execution of first and second platform specific processes, 
respectively. (Final Office Action, pg. 3) Applicants traverse. 

The cited col. 23 of Phillips discusses GDB, a standard debugger that runs on the UNIX 
operating system. The source code of GDB is converted to a format compatible with a Microsoft 
"C" compiler running on DOS. Certain standard functions are altered to call their equivalents in 
"C". The GDB DLL retains its command line interface and does not allow Windows 
applications to link to its modules. 

With regard to a command line interface, the cited col. 12 mentions that a debugger 
maintains a command line interface to perform other debugger functions. See also, Phillips, col. 
22, lines 19-25; col. 23, lines 12-14; col. 24, lines 18-22; col. 26, lines 3-7. For instance, 
Phillips mentions that a low level control interface 21 is used to provide system administration of 
the ICE 10 (in-circuit emulator) (Phillips, col. 19, lines 60-66); that the low level control 
interface 21 allows several options to be performed from the command line (Phillips, col. 22, 
lines 19-21); and that the source level debugger is invoked with a DOS command line interface 
(Phillips, col. 24, lines 18-25). 

Although Phillips discusses the use of a command line interface to perform debugger 
related operations, there is no teaching or suggestion in the cited col. 23 of the claimed first and 
second platform-independent processes that invoke and communicate with first and second 
command line interfaces of first and second operating systems to effect execution of first and 
second platform specific processes, respectively. 
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In the Advisory Action (second point of contention), the Examiner restated his finding on 
pg. 14 of the Final Office Action that the "prior art teaches how GDB (Unix based) 
communicates with Windows applications via ASCII in command line windows, which are 
retained." (Final Office Action, pg. 14) Applicants request review of this finding because the 
cited col. 23 just mentions that the debugger (GDB) retains a command line interface. This 
mention of a debugger retaining a command line interface nowhere teaches, suggests or mentions 
first and second common platform independent processes executing on first and second 
processors separately invoking and communicating with first and second command line 
interfaces of first and second operating systems to effect execution of first and second platform 
specific processes in a SAN as claimed. 

Moreover, the cited col. 23 teaches away from the examiner's point that the GDB 
communicates with windows because col. 23 in fact states that the "GDB [debugger] DLL ... 
does not allow Windows applications to directly link to its modules." (Phillips, col. 23, lines 60- 
63). 

Thus, even if one were to modify Bates with Phillips, Phillips discussion of the use of 
command line interfaces would only suggest that one may use command line interfaces in the 
systems of Bates. However, such proposed modification nowhere teaches or suggests the 
specific claimed use of command line interfaces, i.e., that first and second platform-independent 
processes invoke and communicate with first and second command line interfaces of first and 
second operating systems to effect execution of first and second platform specific processes, 
respectively, as claimed. 

Applicants further request review of the rejection of claims 4, 16, and 23 which depend 
from claims 1,15, and 21, respectively, and further require a manager in communication with the 
first and second common platform-independent process to transmit requests thereto for 
information regarding one or more components of the SAN. 

The Examiner cited col. 13, line 29 to col. 14, line 60 of Bates as teaching the 
requirements of claim 4. (Final Office Action, pg. 5) Applicants traverse. 

The cited cols. 13-14 of Bates mentions that a storage allocator maps or masks available 
storage space to present to hosts. The cited cols. 13-14 further mentions virtual LUN partitions 
and storage security. Each host, having different operating systems, has access to separate non- 
overlapping physical LUNs. The storage allocator may be controlled by a user interface to 
manually configure the allocation of storage. The storage allocator is implemented in a SAN 
appliance or device. Users may use a GUI to allocate storage using the storage allocator. Bates 
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further mentions that the storage allocator receives I/O requests from servers, maps the data I/O 
requests to physical storage I/O requests and forwards them to storage. (Bates, col. 3, lines 37- 
41). 

In the Advisory Action (third point of contention), the Examiner maintained that the cited 
cols. 13-14 of Bates teaches how hosts with different operating systems can access SAN 
components, which is deemed equivalent to the claimed trait. 

Applicants request review of this finding because the Examiner has not cited any part of 
Bates that teaches or suggests that the cited storage allocator performs the claimed operation of 
transmitting requests to first and second common platform-independent processes as claimed. 
For instance, the Examiner has not cited any part of Bates teaching that the storage allocator 
submits requests to first and second platform independent processes that effect execution of first 
and second platform-specific processes, where the platform independent and platform specific 
processors execute on a same digital data processor. 

Applicants further request review of the rejection of dependent claims 5 and 24 in view 
of the above discussed storage allocator cols. 13-14 of Bates. (Final Office Action, pg. 6) 

Applicants request review because the claims require, via the base claims 1 and 21, that 
the first and second common-platform independent processes and the first and second platform 
specific processes execute on the same first and second digital data processors, respectively. The 
cited storage allocator is implemented in a separate device from the servers and storage and 
receives requests from the servers for storage. See , FIG. 7 of Bates. Thus, Bates does not teach 
or suggest that the platform independent and platform-specific process effected by the platform 
independent process are on the same digital data processor. In fact, Bates teaches away because 
cited Bates shows that the storage allocator is a separate device from the servers ("In 
embodiments, the storage allocator of the present invention is based independently of a host", 
Bates, col. 9, lines 34-36) 

In the fourth point of contention mentioned in the Advisory Action, the Examiner found 
that Bates' teaching of hosts with different operating systems accessing SAN components makes 
it inherent that communication between SAN components and the platform independent 
processes must occur. Applicants submit that this finding by the Examiner does not address the 
point that Bates discussion of a storage allocator "based independently of a host" does not teach 
the claim requirement that the platform independent and platform-specific process effected by 
the platform independent process are on the same digital data processor. 
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Further, the Examiner has not cited any part of Bates that teaches or suggests that the 
storage allocator invokes platform specific processes on the servers in response to a request from 
a manger. Instead, Bates mentions that the storage allocator receives read and write requests 
from servers and determines physical storage location on which to store the data and outputs the 
read and write requests to physical storage. (Bates, col. 3, line 54 to col. 4, line 5). 

Applicants request review of the Examiner rejection of claims 6 and 25 in view of col. 3, 
lines 37-67 of Bates and the previously discussed col. 8 of Bates and col. 23 of Phillips as 
teaching the additional requirements of claim 6. (Final Office Action, pg. 7, Advisory Action - 
fifth point of contention) 

The cited col. 3 discusses a network of servers with different operating systems, a storage 
allocator and storage, where the storage allocator receives read and write requests from the 
server to determine the storage locations for the request. The discussed cited col. 23 of Phillips 
discusses a debugger that has a command line interface through which it may be invoked. ) 
Nowhere do the cited Phillips and Bates anywhere teach or suggest separate first and second 
platform specific processes executing on different processors having different operating systems 
gathering information on SAN components and transmit the gathered information to the standard 
output/error. 

Applicants further request review of the rejection of claims 9, 18, and 26 in view of the 
cited col. 15, lines 5-22 of Bates as teaching a query and col. 3, lines 46-67 of Bates as teaching 
multiple processors and platform specific operations. (Final Office Action, pg. 9) 

The cited col. 15 mentions that the storage allocator is implemented in a platform 
independent language, such as Java query language. The cited col. 3 discusses how the storage 
allocator provides access to storage to servers having different operating systems. Although the 
cited Bates mentions that the storage allocator is in a platform independent language query 
language, nowhere does the cited Bates (or Phillips) anywhere teach or suggest the claim 
requirement that the storage allocator uses a query engine for the claimed purpose transmitting 
requests to first and second common platform independent processes on different processors 
having different operating systems as claimed. 

Dated: November 14, 2006 By: /David Victor/ 

David W. Victor 
Registration No. 39,867 
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